home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0073.001 < prev    next >
Text File  |  1993-07-28  |  4KB  |  107 lines
  1.  
  2.  
  3.   | Document: FSC-0073
  4.   | Version:  001
  5.   | Date:     28th July 1993
  6.   | Author:   John Mudge
  7.  
  8.  
  9.                 ENCRYPTED MESSAGE IDENTIFICATION FOR FIDONET
  10.                                 *DRAFT I* 
  11.                         FIDONET TECHNICAL COMMENT
  12.  
  13.                            Author :  John Mudge
  14.                            Fido   :  1:352/111
  15.                            Date   :  25FEB1993
  16.  
  17. ABSTRACT:
  18.  
  19. The following document proposes a standard for encrypted message 
  20. identification for Fidonet and Fidonet-based electronic mail
  21. systems.
  22.  
  23. The proposed standard will assist in encrypted-message detection.
  24. The standard consists of mandatory and suggested portions; however 
  25. the term "mandatory" does not mean that any Fidonet product must 
  26. implement this standard; it simply means that those that do claim
  27. to implement this standard must do so in the way described.
  28.  
  29. STATUS OF THIS DOCUMENT:
  30.  
  31. This FSC suggests a proposed protocol for the Fidonet(R) 
  32. community, and requests discussion and suggestions for 
  33. improvements.  Distribution of this document is unlimited.
  34.  
  35. Fido and Fidonet are registered marks of Tom Jennings and Fido 
  36. Software.
  37.  
  38. BACKGROUND:
  39.  
  40. Currently, Fidonet encrypted messages are not uniquely identified.  
  41. A variety of schemes are in place to determine whether a message 
  42. received by a Fidonet node has been encrypted, but all of them 
  43. involve encryption method specific tests.  Current Fido Policy 
  44. (Policy4) prohibits routing encrypted material through systems which
  45. have not given specific prior approval.  This FSC proposes a method
  46. of identifying such traffic, but makes no effort to determine what
  47. action should be taken after the identification.
  48.  
  49. IFNA KLUDGE LINES:
  50.  
  51. Fidonet supports a general method for sending additional information 
  52. embedded in a message known as the "IFNA kludge line".  This is a 
  53. line of text beginning with the ASCII SOH character (^A).  The 
  54. characters following SOH are a word indicating the type of kludge 
  55. line, and the remainder of the line contains information specific 
  56. to that type.  This standard introduces a new type of kludge line,
  57. the ENC.
  58.  
  59. FORMAT OF A MESSAGE ID - MANDATORY:
  60.  
  61. The mandatory portion of the ^AENC line shall consist of the Ascii SOH 
  62. character immediately followed by the uppercase characters ENC and a 
  63. colon and one space.
  64.  
  65. FORMAT OF A MESSAGE ID - SUGGESTED:
  66.  
  67. It is suggested, though not required, that the unique part of all 
  68. ^AENC lines consist of a unique product identifier following the 
  69. same format as specified in FSC-0046 for ^APID kludge lines and
  70. identifying the program used for encryption.  This product identifier
  71. will allow message editors to invoke the appropriate decryption 
  72. software.
  73.  
  74. EXAMPLE:
  75.  
  76. ^AENC: PGP2.1
  77. with PGP21 to be replaced with a two digit hex identifier at such
  78. time as a central product registry exists.
  79.  
  80. IMPLEMENTATIONS:
  81.  
  82. As of this writing, several products are being written, notably by 
  83. Fredric Rice and GK Pace, to implement this proposal.  Examples of
  84. currently available programs are GENMSG V1.30 and PGP-TOSS.
  85.  
  86. SUMMARY:
  87.  
  88. As of this date, no public repository exists for encryption/decryption
  89. product registration, but the FTSC is suggested as is the application 
  90. form presented in FSC-0022.
  91.  
  92. I am publishing this information as a Fidonet technical comment in hopes
  93. that other Fidonet products will eventually incorporate all or part of 
  94. this standard as well, and that it will eventually form part of a 
  95. Fidonet Technical Standard.
  96.  
  97. CREDITS:
  98.  
  99. I would like to thank all of the pioneers of Fidonet for making all of 
  100. this possible.  The ^AENC proposal is the result of the collective 
  101. efforts of many of the participants of the Fido PUBLIC_KEYS echo.  Much
  102. of the wording and structure for this document I stole from authors of
  103. previous FSC authors.  Special thanks go to GK Pace and Fredric Rice for
  104. their ongoing programming efforts in support of public-key encryption 
  105. systems.
  106.  
  107.